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REMARKS/ARGUMENTS 

The Office Action of December 19, 2003 has been carefully reviewed and this response 
addresses the Examiner's concerns stated in the Office Action. All objections and rejections are 
respectfully traversed. 

Claims 1-31 are still pending in the application. Claim 29 has been amended in 
accordance with Examiner's suggestion to render claim 29 allowable. Dependent claims 32 and 
33 have been added. Since claims 32 and 33 depend from allowable claim 29, they are also 
considered allowable. Claims 1-1 1, 13, 17, 22, and 31 have been amended for purposes of 
clarity and correction of typographical errors and not as being needed to avoid the cited 
references. Paragraphs 1, 9, 14, 16, 19, 42, 54, 55, 81, 112, 115, 123, 127 of Applicants' 
specification, and the Abstract of Applicants' specification have been amended for purposes of 
clarity and correction of typographical errors. All amendments are supported by the 
specification, including drawings, and do not introduce new matter. 

On page 2, paragraph 2.1 of the Office Action, Examiner has objected to the drawings 
because the description of FIG. lA on line 4 of paragraph 42 on page 1 1 describes the service 
controller as 106b and bicontroUer as 106a. Examiner further states that the reference numbers 
in the specification should be changed. Applicants have herein amended the specification 
(paragraph 42) to correct the reference number mismatch, without the introduction of any new 
matter. 

On page 2, paragraph 2.2 of the Office Action, Examiner has objected to the drawings as 
failing to comply with 37 C.F.R. § 1.84(p)(5) because they include reference sign 420 in FIG. 4B 
that is not mentioned in the description. Applicants have herein amended the specification 
(paragraph 81) to include reference sign 420, without the introduction of any new matter. 

On page 2, paragraph 2.3 of the Office Action, Examiner has objected to the drawings as 
failing to comply with 37 C.F.R. § 1.84(p)(5) because they do not include the reference sign 710 
in Fig. 7. Examiner suggests amending the specification to replace reference sign 710 with 
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reference sign 134. Applicants have herein amended the specification (paragraphs 55 and 1 15) to 
include reference sign 134, without the introduction of any new matter. 

On page 2, paragraph 2.4 of the Office Action, Examiner has objected to the drawings as 
failing to comply with 37 C.F.R. § 1.84(p)(5) because they do not include the reference sign 
1014 in Fig. lOB. Applicants respond that reference sign 1014 is included on drawing Fig. lOB, 
but reference sign 1014 is not referred to in the specification. Apphcants have herein amended 
the specification (paragraph 127) to include reference sign 1014, without the introduction of any 
new matter. 

On page 3, paragraph 3.1 of the Office Action, Examiner has objected to the Abstract of 
the disclosure because the reference to the checksum value (407) is said to be placed in an 
integrity element (402), but Fig. 4A does not clearly show such a relationship. Examiner 
suggests changing the abstract to reflect the diagram depicted in Fig. 4A. Applicants have herein 
amended the Abstract so that reference signs 401a are changed to reference signs 401b and 
reference signs 402 are changed to reference signs 404, without the introduction of any new 
matter. 

On page 3, paragraph 3.2 of the Office Action, Examiner has objected to the disclosure 
because the status and serial numbers of nonprovisional related applications(s) (whether patented 
or abandoned) are not included. Applicants have herein amended the specification (paragraph 1) 
to include the serial number and filing date for each related patent application referred to in the 
specification. 

On page 4, paragraph 3.3 of the Office Action, Examiner has noted the use of trademarks 
in the application. Examiner states that trademarks should be capitahzed and be accompanied by 
generic terminology. Applicants have herein amended the specification (paragraphs 9, 55, and 
123) to include capitalized trademarks followed by generic terminology where necessary. 

On page 4, paragraph 3.4 of the Office Action, Examiner has objected to the disclosure 
because the phrase "executable code" has been unnecessarily repeated twice in paragraph 16. 
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Applicants have herein amended the specification (paragraph 16) to delete the unnecessary 
words. 

On page 4, paragraph 3.5 of the Office Action, Examiner has objected to Claim 1 because 
Examiner states that "whereby" is non-functional language. At Examiner's suggestion, 
Applicants have herein amended Claim 1 to change "whereby" to "wherein". 

On page 4, paragraph 3.6 of the Office Action, Examiner has objected to Claims 3, 13, 
17, 22, 29, and 31 because Examiner states that "XML" has not been defined in the specification. 
Applicants respectfully refer Examiner to the specification (paragraph 48) in which "XML" is 
defined. Applicants have herein amended Claims 3, 13, 17, 22, and 29 to define "XML" for 
clarification purposes, and have moved the definition of XML to the first occurrence of its use in 
the specification (paragraph 19). 

On page 5, paragraph 4.1 of the Office Action, Examiner has stated that the application 
names joint inventors. Applicants confirm that the subject matter of the claims was commonly 
owned at the time any inventions covered therein were made. 

On page 5, paragraph 4.2 of the Office Action, Examiner has rejected claims 1-3 under 
35 U.S.C. § 103(a) as being unpatentable over RFC 793 - Transmission Control Protocol 
Specification (TCP). Please note that claim 1 is the base claim for claims 2 and 3. Claims 1-3 
have been amended for clarification purposes. The term "apparatus" has been changed to 
"system" to better define the invention. 

For a better understanding of the patentable distinction between Applicants' claimed 
invention and the Protocol Layering (herein referred to as TCP Stack) defined in Figure 1, page 
2, of the TCP specification, cited by the Examiner and apphed against certain claims of the 
Applicants' invention, Applicants provide herein a comparison of Applicants' Protocol Stack to 
the TCP Stack. Both Applicants' Protocol Stack and the TCP Stack can be separately compared 
to the standard Open Systems Interconnection (OSI) Protocol Stack as shown in the following 
Comparison Chart. The relationship between Applicants' Protocol Stack and the OSI Protocol 
Stack is disclosed in Applicants' specification. The relationship between the TCP Stack and the 
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OSI Protocol Stack is shown in, for example, http://rrfh.hackerstavem.com/K-base/TCP-IP-OSI- 
Modle.html . The OSI Protocol Stack is used as a visual bridge between Applicants' Protocol 
Stack and the TCP Stack. This visual bridge illustrates the patentable distinctions between (1) a 
system that adheres to the structure defined by the OSI Protocol Stack through implementation of 
the TCP specification, and (2) Applicants' system which adheres to the structure defined by the 
OSI Protocol Stack through an implementation of Applicants' system. 
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Applicants* invention is directed to a system for broadcasting information to devices, 
such as, but not limited to, handheld electronic devices. As is disclosed in Applicants' 
specification paragraphs 88-98, AppUcants' system leverages off of existing conventional 
protocol stack mandatory layers that include, but are not limited to, Physical and Link Access 
Layers. As shown in the Comparison Chart, AppUcants' Physical Layer and Framer (disclosed 
in Applicants' specification paragraph 94) correspond to the OSI Physical Layer. Applicants' 
Link Access Layer (LAP) corresponds to the OSI Data Link Layer (see Applicants' specification 
paragraph 95). AppUcants' Software Modules (disclosed in Applicants' specification paragraph 
97) correspond to OSI Network Layer, OSI Transport Layer, OSI Session Layer, OSI 
Presentation Layer, and OSI Application Layer. 

On the contrary, Applicants respectfully point out to the Examiner that theJTCP 
specification is directed to a system that manages two-way communication between processes. 
The TCP Stack Network Interface Layer corresponds to the OSI Data Link Layer and the OSI 
Protocol Stack Physical Layer, while the TCP Stack Intemet Protocol (IP) Layer corresponds to 
the OSI Protocol Stack Network Layer. AppUcants further respectfully point out to the 
Examiner that the TCP Stack TCP Layer, which requires the protocol defined in the cited TCP 
specification, corresponds to the OSI Protocol Stack Transport Layer and part of the OSI 
Protocol Stack Session Layer. The TCP Stack Application Layer corresponds to part of the OSI 
Protocol Stack Session Layer, the OSI Protocol Stack Presentation Layer, and the OSI Protocol 
Stack Application Layer. Furthermore, the protocol of the TCP Stack's TCP Layer manages 
process-to-process communication, while the protocol of the TCP Stack's IP Layer manages the 
message's interaction with the intemet. Each layer in the TCP Stack provides a header and 
"data" within the network message. The header provided by the TCP Layer and set forth in the 
TCP specification directs the data within the part of the message managed by the TCP Layer (the 
TCP "data!') to a receiving application through its routing information. The TCP "data" are 
processed according to the dictates of the receiving application, but their contents are not 
discussed nor specified in the TCP specification. 
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A typical message transmitted by Applicants' system would have the following format 
(see Applicants' specification Fig. 4A) where indentations indicate that the indented element is 
regarded as "data" by the previous level of the message: 



PHYSICAL INTERFACE REQUIRED INFORMATION 
LINK ACCESS REQUIRED INFORMATION 
INTEGRITY ELEMENT 1 
WINDOW 1 

INTEGRITY ELEMENT 2 
WINDOW 2 

INTEGRITY ELEMENT 3 
WINDOWS 



In comparison, a typical message transmitted by a TCP Stack system would have the 
following format, where indentations indicate that the indented element is regarded as "data" by 
the previous level of the message: 



NETWORK INTERFACE HEADER 
NETWORK INTERFACE DATA: 
IP HEADER 
IP DATA: 

TCP HEADER 
TCP DATA: 

APPLICATION HEADER 
APPLICATION DATA 



In contrast to the TCP Layer's requirements set out in the TCP specification, Applicants 
respectfully point out to the Examiner that Applicants' Software Modules do not need to, for 
example, provide source and destination routing information, nor sequencing information, nor 
acknowledgement and resend information. Ap^licants^jnessage is broadcast, and any_receiver 
^ can choose to accept ordisre gard the messa ge, depending on the contents, not on TCP-type 
frouting^information. Therefore, nojpp-ty pe routing information is necessary with Applicants' 
system. The transmitter within Applicants' system does not track which receivers accept 
Applicants' message. Applicants' system eliminates the overhead of the TCP Stack's TCP 
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Layer, as well as the IP and Application Layers, because the structure of those layers is not 
needed for Applicants' system. Applicants' system does require, however, that the data of the » 
transmitted message be specially formatted (requiring parsing, size, and checksum information) 



With respect to many of the claim rejections, Examiner equates Applicants' "parsing" 
with TCP's "packeting" and "packaging". On the contrary, Applicants respectfully assert to the 
Examiner that parsing is an intelligent determination of the contents of the bits that are being 
processed for transmission, whereas packeting and packaging refer to associating data bits with a 
header regardless of the contents of the bits. As is commonly known in the art (see, for example, 
XML Black Book Pitts-Moultis, N., and Kirk, C, ISBN 1-57610-284-X, 1999, p. 337), and as is 
disclosed in AppHcants' specification, parsing involves at least some measure of interpretation of 
the data. In Applicants' system, the data are parsed by the transmitter such that they are prepared 
for immediate use by the receiver without pre-processing. 

Examiner equates Applicants' "integrity element" with the "header" set forth in the TCP 
specification. As was discussed above. Applicants' system does not need a TCP header, nor for 
that matter an IP header or an Application Layer header. Applicants' context-related frames are 
bound by integrity elements that include size and checksum information, and none of the other 
required fields set forth in the TCP specification. Not included in the integrity element is any 
kind of routing information such as source and destination processes, because the integrity 
element is not a header such as the TCP specification discloses. 

Examiner equates TCP packets with Applicants' broadcast signals. Applicants 
respectfully assert that, in networking, a distinction is made between broadcast, multicast, and 
unicast. Broadcast, or broadcast signal, as defined in Applicants' specification, denotes a one- 
way communication signal going from an originating location to one or more terminating 
locations. The protocol defined in the TCP specification supports and requires handshaking 
between sender and receiver. Applicants' system provides no means to perform such 
handshaking at the level of Applicants' Software Modules. Instead, messages having meaningful 
content are prepared and transmitted to any receiver that might be in the range of the transmitter. 



so that the receiver can interpret incoming messages. 




Page 22 of 41 



Appl. No. 09/930,004 
Amdt. Dated March 17, 2004 

Reply to Office Action of December 19, 2003 , 
Docket No.: 12078-140 

At the level of Applicants' Software Modules, the receiver does not acknowledge the message as 
is required by the protocol defined in the TCP specification. 

With respect to claim 1, Examiner states that TCP substantially teaches of creating and 
transmitting data signals (i.e. segments/packets/frames) through a communication medium to 
receivers (paragraph 1 on page 4). Examiner states that TCP further teaches of parsing (or 
packeting or packaging) bytes into frames (or packets) containing a subset of the bytes 
(paragraph 1 on page 4). The TCP specification, paragraph 1, page 4 states, "[T]the TCP is able 
to transfer a continuous stream of octets in each direction between its users by packaging some 
number of octets into segments for transmission through the internet system. In general, the 
TCPs decide when to block and forward data at their own convenience." Nowhere doe s the TCP 
specification disclose parsing. TCP "packages" some number of octets together for transmission. 
TheTdetermmation of the number of octets that form a data packet xmder TCP has nothing to do 
with the content of the data, therefore parsing is not done to TCP "data". 

Examiner states that TCP further teaches of computing a checksum over the data 
(Checksum paragraph on page 16). Nowhere does TCP teach computing a checksum over a 
subset of the plurality of bytes that has been parsed. The checksum of TCP is computed for the 
data packet, not for any subset of the data packet, nor is the checksum computed based on any 
type of parsing. 

Examiner states that TCP further teaches of providing an integrity element (pages 15-17) 
which Examiner is interpreting as a header since. Examiner states, it is essentially made of data 
(i.e. checksum, size, etc.) that will help determine the vaHdity of the data frame. Examiner states 
that TCP teaches of an integrity element that contains the checksum and how the header 
associates with one packet (pages 15-17). On pages 15-17 of the TCP specification, a header is 
disclosed that contains required elements as follows: a Source Port, a Destination Port, a 
Sequence Number, an Acknowledgment Number, a Data Offset, Control Bits, a Window (an 
octet counter), a Checksum, and a pseudo header conceptually prefixed to the TCP header. This 
pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP 
length and gives the TCP protection against misrouted segments. Nowhere does the TCP 

Page 23 of 41 



Appl. No. 09/930,004 

Amdt. Dated March 17, 2004 

Reply to Office Action of December 19, 2003 

Docket No.: 12078-140 

provide for an integrity element as defined in Applicants' specification that includes only 
checksum information and the size of the parsed subset. 

Examiner states that TCP teaches how the integrity element, specifically the checksum, 
can be used to determine if the received frame/data subset is intact/valid or damaged (paragraph 
3 on page 4). Nowhere does TCP teach Applicants' frame, nor is the TCP checksum computed 
for any finer granularity than TCP data, i.e. no checksums are specified to be computed by the 
TCP for parts or subsets of the data in a TCP packet. 

Examiner states that TCP teaches how the header and data are sent together as segments 
(paragraph 1 on page 15). Examiner equates segments with broadcast signals and states that 
TCP teaches that the broadcast signals are transferred in both directions, and hence that TCP 
teaches the limitation of transmitting signals to receivers (paragraph 1 on page 4). Examiner 
states that TCP teaches of transmitting the signals over an established connection, and hence that 
TCP teaches the limitation of transmitting through communication medium to the device 
(paragraph 6 on page 40). Nowhere does the TCP specification disclose broadcasting or 
broadcast signals. 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the reference itself or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference. Second, there must 
be a reasonable expectation of success. Finally, the prior art reference must teach or suggest all 
the claim limitations. The teaching or suggestion to make the claimed combination and the 
reasonable expectation of success must both be found in the prior art, not in Applicants' 
disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). Further, obviousness 
can only be established by combining or modifying the teachings of the prior art to produce the 
claimed invention where there is some teaching, suggestion, or motivation to do so found either 
explicitly or implicitly in the references themselves or in the knowledge generally available to 
one of ordinary skill in the art. Since the TCP specification does not teach or suggest each and 
every element of AppHcants' claim 1, either expressly or inherently. Applicants' claim 1 (as well 
as claims 2-4 that depend therefrom and that fiirther define the invention) is not made obvious by 
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the TCP specification and a rejection under 35 U.S.C. § 103(a) is inappropriate. Therefore, 
Applicants respectfully request the withdrawal of rejections under 35 U.S.C. § 103(a) with 
regards to claims 1-4 for the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants* claimed 
invention over the TCP specification are provided below. 

With respect to claim 2, Examiner states that TCP teaches of an integrity element that 
comprises a size value (paragraph 2 on page 17), Examiner states that it would have been 
obvious to one skilled in the art to include both the checksum operation and seed value. 
Examiner states that the need to transmit the operator along with the integrity element is not 
clear. Examiner states that it is unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth and calculation time. Nowhere does 
the TCP specification disclose an operator identifying a mathematical operator used to compute 
the checksum, nor does the TCP specification disclose a seed value. These values make it 
possible for the sender and receiver to be decoupled as to the specifics of error checking. This 
sort of flexibility is not disclosed or suggested in the TCP specification. The TCP specification 
could have made this aspect of communications flexible, as it did with the size of the TCP header 
(indicated by the Data Offset field), and the amount of data in the packet (indicated by the 
Window field). The TCP forces both sender and receiver to perform error checking in exactly 
the same way. Applicants' protocol allows for variation. It is impermissible hindsight for 
Examiner to suggest that making a protocol more flexible in order to accomplish AppHcants' 
goal of broadcasting context-dependent material to a receiver without the overhead of TCP and 
related headers is obvious to one skilled in the art, considering that there is no suggestion 
whatsoever in the TCP specification to provide such flexibility. Further, since Applicants assert 
that claim 1 should now be considered to be allowable. Applicants respectfully request that 
Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 2 and find claim 2 to 
be allowable. 

With respect to claim 3, Examiner states that it would have been obvious to one skilled in 
the art to have the data signal contain an XML element. Examiner states that the frame/packet 
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can be comprised of almost any type of transferable data. Applicants agree that almost any type 
of electronic data could be included in Applicants' frame. Since Applicants assert that claim 1 
should now be considered to be allowable, Applicants respectfully request the Examiner 
withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 3 and find claim 3 to be 
allowable. 

On page 8, paragraph 4.3, of the Office Action, Examiner has rejected claim 4 under 35 
U.S.C. § 103(a) as being unpatentable over TCP in view of admitted prior art "Specifications" 
(Specs). Examiner states that TCP substantially teaches the limitations of claim 4. Examiner 
states that TCP does not teach of transmitting the signal as a diffuse infrared signal. Examiner 
states that TCP teaches of establishing communication connections. Examiner states that Specs, 
in an analogous art, teaches of diffuse optical communication as a common optical 
communication protocol (paragraph 88 on page 28). Examiner states that it would have been 
obvious to one skilled in the art to transmit a packet of TCP data using optical communication 
protocol. Examiner states that one skilled in the art would have been motivated by the 
suggestion provided by Specs that diffuse optical conununication protocol is a commonly used 
protocol and hence communication method. Since Applicants assert that claim 1 should now be 
considered to be allowable, Applicants respectfully request that Examiner withdraw the rejection 
under 35 U.S.C. § 103(a) directed to claim 4 and find claim 4 to be allowable. 

On page 8, paragraph 4.4, of the Office Action, Examiner has rejected claims 5-9 under 
35 U.S.C. § 103(a) as being unpatentable over TCP. 

With respect to claim 5, Examiner states that TCP substantially teaches of exchanging 
segments/packets having a plxirality of bytes (paragraph 1 on page 4, paragraph 6 on page 40). 
Examiner equates TCP segments/packets with Applicants' data/broadcast signals. Examiner 
states that TCP further teaches of creating packets and headers to transmit data (paragraph 1 on 
page 4, pages 15-17). Examiner equates TCP headers with AppUcants' integrity elements. 
Examiner states that TCP teaches using the checksum to ensure reliability (paragraph 3 on page 
4). Examiner states that by teaching of creating the data and communicating/transferring it in a 
specific manner, Examiner is interpreting that TCP is teaching of both how to send and how to 
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receive data. Examiner states that it is clear that if TCP teaches of how to create packets and 
associated headers and how to combine the packets and headers (i.e. append the header to the 
packet), then TCP teaches how to detect and separate packets as well. Examiner states that it is 
clear that TCP teaches of determining the contents of the header and that TCP explicitly teaches 
of using the checksum to disregard damaged packets (paragraph 3 on page 4). The TCP 
specification, paragraph 1, page 4 states, "[T]the TCP is able to transfer a continuous stream of 
octets in each direction between its users by packaging some number of octets into segments for 
transmission through the internet system. In general, the TCPs decide when to block and 
forward data at their own convenience." The TCP specification pages 15-17 disclose the format 
of a TCP header. Paragraph 3 on page 4 discloses adding a checksum to each segment 
transmitted, checking it at the receiver, and discarding damaged segments. Nowhere does the 
TCP specification disclose Applicants' claimed means for detecting a frame and an integrity 
element. As discussed previously, the packets and headers of TCP are not equivalent to 
Applicants' claimed frames and integrity elements. Nowhere does the TCP specification 
disclose an integrity element that contains only a checksum operator, a checksum seed, and a 
size. The TCP specification discloses a header that requires many more fields. Further, nowhere 
does the TCP specification disclose any possible us^ora check sum o peratorjinda^hecksum 
s^ed^he err or detection mech anism of TCP being clearly limited by the TCP specification. 

Since the TCP specification does not teach or suggest each and every element of 
Apphcants* claim 5, either expressly or inherently, Applicants' claim 5 (as well as claims 6-9 that 
depend therefrom and that fiirther define the invention) is not made obvious by the TCP 
specification and a rejection under 35 U.S.C. § 103(a) is inappropriate. Therefore, Applicants 
respectfully request the withdrawal of rejections under 35 U.S.C. § 103(a) with regards to claims 
5-9 for the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants' claimed 
invention over the TCP specification are provided below. 

With respect to claim 6, Examiner states that TCP substantially teaches the limitations of 
claim 6. Examiner states that TCP further teaches of a checksum that is calculated over its 
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associated packet (pages 15-17, Checksum paragraph on page 16). Nowhere does the TCP 
specification disclose Applicants' claimed integrity element. Further, since Applicants assert 
that claim 5 should now be considered to be allowable, Applicants respectfully request that 
Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 6 and find claim 6 to 
be allowable. 

With respect to claims 7 and 8, Examiner states that TCP substantially teaches the 
limitations of claim 7. Examiner states that TCP further teaches of checking a checksum at the 
receiver to ensure that the segment is not damaged (paragraph 3 on page 4) Examiner states that 
if the checksum is calculated upon receipt and matches the transmitted checksum, then the 
packet will be validated, otherwise, when the two checksums don't match, the "damaged" one 
will be discarded or invalidated. Nowhere does the TCP specification disclose validating a 
checksum in a frame, herein defined as a subset of a TCP data packet. Nowhere does the TCP 
specification disclose an integrity element containing the checksum. Further, since claim 5 now 
appears to be allowable. Applicants respectfully request that Examiner withdraw rejections under 
35 U.S.C. § 103(a) directed to claims 7 and 8 and find claims 7 and 8 to be allowable. 

With respect to claim 9, Examiner states that TCP substantially teaches the limitations of 
claim 9. Examiner states that TCP teaches of a header that comprises a size value (paragraph 2 
on page 17) where the TCP length is described. Examiner states that it would have been obvious 
to one with skill in the art to include both the checksum operation and seed value if these values 
were not previously agreed upon by the communication devices. Examiner states that it is 
common to calculate checksums with XOR or mod 2 arithmetic. Examiner states that the 
specifications do not teach any checksum calculation techniques other than XOR when 
disclosing known techniques to calculate the checksum, and therefore the need to transmit the 
operator along with the integrity element is not clear. Examiner states that it is not clear why the 
checksum operation and seed values are not uniformly agreed upon beforehand so as to save 
bandwidth. Apphcants refer Examiner to the arguments above with respect to claim 2. Further, 
since claim 5 now appears to be allowable, Applicants respectfully request that Examiner 
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withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 9 and find claim 9 to be 
allowable. 

On page 1 1, paragraph 4.5, of the Office Action, Examiner has rejected claims 10 and 1 1 
under 35 U.S.C. § 103(a) as being unpatentable over TCP in view of admitted prior art Specs. 

With respect to claim 10, Examiner states that TCP substantially teaches the limitations 
of claim 10. Examiner states that TCP does not teach of transmitting the signal as a diffuse 
infrared signal. Examiner states that TCP teaches of establishing communication connections. 
Examiner states that Specs, in an analogous art, teaches of diffuse optical communication as a 
common optical conmiunication protocol (lines 3-6, paragraph 88 on page 28). Examiner states 
that it would have been obvious to one skilled in the art to transmit packet of TCP using optical 
communication protocol. Examiner states that one skilled in the art would have been motivated 
by the suggestion provided by Specs that diffuse optical communication protocol is a commonly 
used protocol and hence communication method. Since claim 5 now appears to be allowable, 
Applicants respectfully request the Examiner withdraw the rejection under 35 U.S.C. § 103(a) 
directed to claim 10 and find claim 10 to be allowable. 

With respect to claim 1 1, Examiner states that TCP substantially teaches the limitations 
of claim 11. Examiner states that TCP does not teach of data signal being created by modulating 
an electric light. Examiner states that Specs, in an analogous art, teaches of modulating an 
electric light to generate optical signals as being known in the art (lines 1-5, paragraph 161 on 
page 55). Examiner states that it would have been obvious to one with skill in the art to create 
packets of TCP by modulating an electric light. Since claim 5 now appears to be allowable. 
Applicants respectfully request that Examiner withdraw the rejection under 35 U.S.C. § 103(a) 
directed to claim 1 1 and find claim 1 1 to be allowable. 

On page 12, paragraph 4.6, of the Office Action, Examiner has rejected claims 12, 13, 
and 15 under 35 U.S.C. § 103(a) as being unpatentable over TCP. 

With respect to claim 12, Examiner states that TCP substantially teaches of creating and 
transmitting packets through a communications medium to receivers (paragraph 1 on page 4). 
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Examiner states that TCP further teaches of packaging bytes into packets containing a subset of 
the bytes (paragraph 1 on page 4). Examiner states that TCP teaches of computing a checksum 
over the data (Checksum paragraph on page 16). Examiner states that TCP teaches of providing 
an integrity element (pages 15-17), which Examiner is interpreting as a header since, Examiner 
states, it is essentially made of data that will help determine the validity of the data frame. 
Examiner states that TCP teaches of a header that contains the checksum and how the header is 
associated with one packet (pages 15-17). Examiner states that TCP teaches how the header, 
specifically the checksum, can be used to determine if the received packet is intact/valid or 
damaged (paragraph 3 on page 4). Examiner states that TCP teaches how the header and data are 
sent together as segments (paragraph 1 on page 15). Examiner states that TCP teaches that the 
segments are transferred in both directions, hence TCP teaches the limitation of transmitting 
signals to receivers (paragraph 1 on page 4). Examiner states that TCP teaches of transmitting 
the signals over an established connection, hence TCP teaches the limitation of transmitting 
through communication medium to the device (paragraph on page 40). Examiner states that TCP 
does not explicitly teach of making the transmission available for handheld devices. Examiner 
states that it would have been obvious to one skilled in the art to make the broadcast signal 
available for a handheld device. 

As discussed above, nowhere does the TCP specification disclose or suggest parsing a 
plurality of bytes into a frame and determining a checksum over that frame. The TCP 
specification calls for the creation of a header that is appended to a certain number of octets of 
unknown content. As is commonly known in the art, and as is disclosed in Applicants' 
specification, parsing involves at least some measure of interpretation of the data. In Applicants' 
invention, the data are parsed such that they are prepared for more efficient use by the receiver. 
The TCP specification clearly does not suggest anything more than data delivery and 
handshaking. Since the TCP specification does not suggest parsing segments of octets (for 
example, Applicants' frames), so it does not suggest error detection for any subsets of data 
within the TCP packets, such as Applicants' frames. Nowhere does the TCP specification 
disclose or suggest an integrity element as defined by Applicants. Nowhere does the TCP 
specification disclose or suggest surrounding frames by integrity elements. The TCP 
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specification groups octets based on the size of the window requested by the receiver (paragraph 
5 on page 4), whereas Apphcants' frames and the position in the data stream of its integrity 
elements is based on the contents of the data being transmitted. Nowhere does the TCP 
specification disclose or suggest a broadcast signal. As discussed above, there is a distinction 
between unicast (TCP) and broadcast (Applicants). Nowhere does the TCP specification suggest 
a strategy for managing the special requirements of a handheld device, specifically, preparing 
data according to the method of claim 12 so that little processing of those data needs to be done 
when the data are received by the handheld device, and in particular, so that no TCP/IP overhead 
is required. Since the TCP specification does not teach or suggest each and every element of 
Applicants* claim 12, either expressly or inherently. Applicants' claim 12 (as well as claims IB- 
IS that depend therefrom and that further define the invention) is not made obvious by the TCP 
specification and a rejection under 35 U.S.C. § 103(a) is inappropriate. Therefore, AppUcants 
respectfiiUy request the withdrawal of rejections under 35 U.S.C. § 103(a) with regards to claims 
12-15 for the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants' claimed 
invention over the TCP specification are provided below. 

With respect to claim 13, Examiner states that it would have been obvious to one of skill 
in the art to have the data signal contain an XML element. Examiner states that the frame/packet 
can be comprised of almost any type of transferable data. Applicants agree that almost any type 
of electronically transferable data could be included in AppHcants' frame. Since claim 12 now 
appears to be allowable, Applicants respectfully request the Examiner withdraw the rejection 
under 35 U.S.C. § 103(a) directed to claim 13 and find claim 13 to be allowable. 

With respect to claim 15, Examiner states that TCP teaches of a header that comprises a 
size value (paragraph 2 on page 17) where the TCP length is described. Examiner states that it 
would have been obvious to one skilled in the art to include both the checksum operation and 
seed value. Examiner states that the need to transmit the operator along with the integrity 
element is not clear. Examiner states that it is unclear why the checksum operation and seed 
values are not uniformly agreed upon beforehand so as to save bandwidth and calculation time. 
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Please see the argument with respect to claim 2. Further, since claim 12 now appears to be 
allowable, Applicants respectfully request the Examiner withdraw the rejection under 35 U.S.C. 
§ 103(a) directed to claim 15 and find claim 15 to be allowable. 

On page 15, paragraph 4.7, of the Office Action, Examiner has rejected claim 14 under 
35 U.S.C. § 103(a) as being unpatentable over TCP in view of admitted prior art Specs. 
Examiner states that TCP substantially teaches the limitations of claim 14. Examiner states that 
TCP does not teach of transmitting the signal as a diffuse infrared signal. Examiner states that 
TCP teaches of establishing communication connections. Examiner states that Specs, in an 
analogous art, teaches of diffuse optical communication as a common optical communication 
protocol (paragraph 88 on page 28). Examiner states that it would have been obvious to one 
skilled in the art to transmit a packet of TCP data using optical communication protocol. 
Examiner states that one skilled in the art would have been motivated by the suggestion provided 
by Specs that diffuse optical communication protocol is a commonly used protocol and hence 
communication method. Since claim 12 now appears to be allowable, Applicants respectfully 
request the Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 14 and 
find claim 14 to be allowable. 

On page 16, paragraph 4.8, of the Office Action, Examiner has rejected claims 16-19 
under 35 U.S.C. § 103(a) as being unpatentable over TCP. 

With respect to claim 16, Examiner states that TCP substantially teaches of exchanging 
segments/packets/data signals having a plurality of bytes (paragraph 1 on page 4, paragraph 6 on 
page 40). Examiner states that TCP further teaches of creating packets and headers to transmit 
data (paragraph 1 on page 4, pages 15-17). Examiner states that TCP teaches using the 
checksum to ensure reliability (paragraph 3 on page 4). Examiner states that by teaching of 
creating the data and communicating/transferring it in a specific manner. Examiner is 
interpreting that TCP is teaching of both how to send and how to receive data. Examiner states 
that it is clear that if TCP teaches of how to create packets and associated headers and how to 
combine the packets and headers (i.e. append the header to the packet), then TCP teaches how to 
detect and separate packets as well. Examiner states that it is clear that TCP teaches of 

Page 32 of 41 



Appl. No. 09/930,004 

Amdt. Dated March 17, 2004 

Reply to Office Action of December 19, 2003 

Docket No.: 12078-140 

determining the contents of the header and that TCP explicitly teaches of using the checksum to 
disregard damaged packets (paragraph 3 on page 4). Examiner states that TCP teaches of a 
checksum that is calculated over its associated packet (pages 15-17, Checksum paragraph, page 
16). Examiner states that TCP further teaches of checking a checksum at the receiver to ensure 
that the segment is not damaged (paragraph 3 on page 4). Examiner states that if the checksum 
is calculated upon receipt and matches the transmitted checksum, then the packet will be 
validated, otherwise, when the two. checksums don't match, the "damaged" one will be discarded 
or invalidated. Please see arguments for claims 5, 6, and 7. Since the TCP specification does not 
teach or suggest each and every element of Applicants* claim 16, either expressly or inherently. 
Applicants' claim 16 (as well as claims 17-19 that depend therefrom and that further define the 
invention) is not made obvious by the TCP specification and a rejection under 35 U.S.C. § 103(a) 
is inappropriate. Therefore, Applicants respectfully request the withdrawal of rejections under 
35 U.S.C. § 103(a) with regards to claims 16-19 for the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants' claimed 
invention over the TCP specification are provided below. 

With respect to claim 17, Examiner states that it would have obvious to one skilled in the 
art to have the data signal contain an XML element. Examiner states that the frame/packet can 
be comprised of almost any type of electronically transferable data. Applicants agree that almost 
any type of transferable data could be included in Apphcants' frame. Since claim 16 now 
appears to be allowable, Applicants respectfully request the Examiner withdraw the rejection 
under 35 U.S.C. § 103(a) directed to claim 17 and find claim 17 to be allowable. 

With respect to claim 18, Examiner states that TCP teaches of discarding the packets if 
the checksums do not match (paragraph 3 on page 4). Since claim 16 now appears to be 
allowable, Applicants respectfully request the Examiner withdraw the rejection under 35 U.S.C. 
§ 103(a) directed to claim 18 and find claim 18 to be allowable. 

With respect to claim 19, Examiner states that TCP teaches of a header that comprises a 
size value (paragraph 2 on page 17) where the TCP length is described. Examiner states that it 
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would have been obvious to one with skill in the art to include both the checksum operation and 
seed value if these values were not previously agreed upon by the communication devices. 
Examiner states that it is common to calculate checksums with XOR or mod 2 arithmetic. 
Examiner states that the specifications do not teach any checksum calculation techniques other 
than XOR when disclosing known techniques to calculate the checksum, and therefore the need 
to transmit the operator along with the integrity element is not clear. Examiner states that it is 
not clear why the checksum operation and seed values are not uniformly agreed upon beforehand 
so as to save bandwidth. Applicants refer Examiner to the arguments above with respect to 
claim 2. Further, claim 16 now appears to be allowable, Applicants respectfully request the 
Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 19 and find claim 19 
to be allowable. 

On page 19, paragraph 4.9, of the Office Action, Examiner has rejected claims 20-22 
under 35 U.S.C. § 103(a) as being unpatentable over TCP. 

With respect to claim 20, Examiner states that TCP substantially teaches of creating and 
transmitting packets through a communications medium to receivers (paragraph 1 on page 4). 
Examiner states that TCP further teaches of packaging bytes into packets containing a subset of 
the bytes (paragraph on page 4). Examiner states that TCP teaches of computing a checksum 
over the data (Checksum paragraph on page 16). Examiner states that TCP teaches of providing 
an integrity element (pages 15-17), which Examiner is interpreting as a header since it is 
essentially made of data that will help determine the vaUdity of the data frame. Examiner states 
that TCP teaches of a header that contains the checksum and how the header is associated with 
one packet (pages 15-17). Examiner states that TCP teaches how the header, specifically the 
checksum, can be used to determine if the received packet is intact/valid or damaged (paragraph 
3 on page 4). Examiner states that TCP teaches how the header and data are sent together as 
segments (paragraph 1 on page 15). Examiner states that TCP teaches that the segments are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers (paragraph 1 on page 4), Examiner states that TCP teaches of transmitting the signals 
over an established connection, hence TCP teaches the limitation of transmitting through 
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communication medium to the device (paragraph on page 40). Examiner states that TCP does 
not expUcitly teach of making the broadcast signal available for transmission to a receiving 
device. Examiner states that it would have been obvious to one skilled in the art to make the 
broadcast signal available for transmission. Examiner states that TCP teaches of a connection 
that is established and data that is communicated between senders and receivers, and therefore 
making the signal available for transmission to a receiving device must occur since TCP teaches 
that a connection is established and data/segments are communicated/exchanged. 

Please see the argument with respect to claim 12. Since the TCP specification does not 
teach or suggest each and every element of Applicants* claim 20, either expressly or inherently. 
Applicants' claim 20 (as well as claims 21-22 that depend therefrom and that further define the 
invention) is not made obvious by the TCP specification and a rejection under 35 U.S.C. §103(a) 
is inappropriate. Therefore, Applicants respectfully request the withdrawal of rejections under 
35 U.S.C. § 103(a) with regards to claims 20-22 for the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants* claimed 
invention over the TCP specification are provided below. 

With respect to claim 21, Examiner states that TCP teaches of a header that comprises a 
size value (paragraph 2 on page 17) where the TCP length is described. Examiner states that it 
would have been obvious to one with skill in the art to include both the checksum operation and 
seed value if these values were not previously agreed upon by the communication devices. 
Examiner states that it is common to calculate checksums with XOR or mod 2 arithmetic. 
Examiner states that the specifications do not teach any checksum calculation techniques other 
than XOR when disclosing known techniques to calculate the checksum, and therefore the need 
to transmit the operator along with the integrity element is not clear. Examiner states that it is 
not clear why the checksum operation and seed values are not uniformly agreed upon beforehand 
so as to save bandwidth. Applicants refer Examiner to the arguments above with respect to 
claim 2. Further, since claim 20 now appears to be allowable. Applicants respectfiiUy request the 
Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to claim 21 and find claim 21 
to be allowable. 
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With respect to claim 22, Examiner states that it would have been obvious to one of skill 
in the art to have the data signal contain an XML element. Examiner states that the frame/packet 
can be comprised of almost any type of transferable data. Applicants agree that almost any type 
of electronically transferable data could be included in Applicants' frame. Since claim 20 now 
appears to be allowable, Applicants respectfully request the Examiner withdraw the rejection 
under 35 U.S.C. § 103(a) directed to claim 22 and find claim 22 to be allowable. 

On page 21, paragraph 4.10, of the Office Action, Examiner has rejected claims 23-24 
under 35 U.S.C. § 103(a) as being unpatentable over TCP in view of admitted prior art Specs. 

With respect to claim 23, Examiner states that TCP substantially teaches the hmitations 
of claim 23. Examiner states that TCP does not teach of transmitting the signal as a diffuse 
infrared signal. Examiner states that TCP teaches of establishing communication connections. 
Examiner states that Specs, in an analogous art, teaches of diffuse optical communication as a 
common optical commimication protocol (paragraph 88 on page 28). Examiner states that it 
would have been obvious to one skilled in the art to transmit packet of TCP using optical 
communication protocol. Examiner states that one skilled in the art would have been motivated 
by the suggestion provided by Specs that diffuse optical communication protocol is a commonly 
used protocol and hence communication method. Since claim 20 now appears to be allowable, 
Applicants respectfully request the Examiner withdraw the rejection under 35 U.S.C. § 103(a) 
directed to claim 23 and find claim 23 to be allowable. 

With respect to claim 24, Examiner states that TCP substantially teaches the limitations 
of claim 24. Examiner states that TCP does not teach of data signal being created by modulating 
an electric light. Examiner states that Specs, in an analogous art, teaches of modulating an 
electric hght to generate optical signals as being known in the art (lines 1-5, paragraph 161 on 
page 55). Examiner states that it would have been obvious to one skilled in the art to create 
packets of TCP by modulating an electric light. Since claim 20 now appears to be allowable, 
Applicants respectfully request the Examiner withdraw the rejection under 35 U.S.C. § 103(a) 
directed to claim 24 and find claim 24 to be allowable. 
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On page 23, paragraph 4.1 1, of the Office Action, Examiner has rejected claims 25-27 
and 3 1 under 35 U.S.C. § 103(a) as being unpatentable over TCP. Applicants have herein 
amended claim 31 to depend upon claim 28. 

With respect to claim 25, Examiner states that TCP substantially teaches of exchanging 
segments/packets/data signals having a plurality of bytes (paragraph 1 on page 4, paragraph 6 on 
page 40). Examiner states that TCP further teaches of creating packets and headers to transmit 
data (paragraph 1 on page 4, pages 15-17). Examiner states that TCP teaches using the 
checksum to ensure reliabihty (paragraph 3 on page 4). Examiner states that by teaching of 
creating the data and communicating/transferring it in a specific manner, Examiner is 
interpreting that TCP is teaching of both how to send and how to receive data. Examiner states 
that it is clear that if TCP teaches of how to create packets and associated headers and how to 
combine the packets and headers (i.e. append the header to the packet), then TCP teaches how to 
detect and separate packets as well. Examiner states that it is clear that TCP teaches of 
determining the contents of the header and that TCP explicitly teaches of using the checksum to 
disregard damaged packets (paragraph 3 on page 4). Please see arguments for claim 5. Since the 
TCP specification does not teach or suggest each and every element of Apphcants* claim 25, 
either expressly or inherently. Applicants' claim 25 (as well as claims 26 and 27 that depend 
therefrom and that further define the invention) is not made obvious by the TCP specification 
and a rejection under 35 U.S.C. § 103(a) is inappropriate. Therefore, Applicants respectfully 
request the withdrawal of rejections under 35 U.S.C. § 103(a) with regards to claims 25-27 for 
the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants' claimed 
invention over the TCP specification are provided below. 

With respect to claims 26 and 27, Examiner states that TCP further teaches of checking a 
checksum at the receiver to ensure that the segment is not damaged (paragraph 3 on page 4) 
Examiner states that if the checksum is calculated upon receipt and matches the transmitted 
checksum, then the packet will be validated, otherwise, when the two checksums don't match, 
the "damaged" one will be discarded or invahdated. Please see arguments for claims 6 and 7. 
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Further, since claim 25 now appears to be allowable, Applicants respectfully request the 
Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to claims 26 and 27 and find 
claims 26 and 27 to be allowable. 

On page 25, paragraph 4.12, of the Office Action, Examiner has rejected claims 28 and 
30 under 35 U.S.C. § 103(a) as being unpatentable over TCP. Applicants have herein amended 
claim 31 to depend upon claim 28, as the original dependence of claim 31 upon claim 26 was a 
typographical error. 

With respect to claim 28, Examiner states that TCP substantially teaches of creating and 
transmitting packets through a communications medium to receivers (paragraph 1 on page 4). 
Examiner states that TCP fiirther teaches of packaging bytes into packets containing a subset of 
the bytes (paragraph on page 4). Examiner states that TCP teaches of computing a checksum 
over the data (Checksum paragraph on page 16). Examiner states that TCP teaches of providing 
an integrity element (pages 15-17), which Examiner is interpreting as a header since it is 
essentially made of data that will help determine the validity of the data fi*ame. Examiner states 
that TCP teaches of a header that contains the checksum and how the header is associated with 
one packet (pages 15-17). Examiner states that TCP teaches how the header, specifically the 
checksum, can be used to determine if the received packet is intact/valid or damaged (paragraph 
3 on page 4). Examiner states that TCP teaches how the header and data are sent together as 
segments (paragraph 1 on page 15). Examiner states that TCP teaches that the segments are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers (paragraph 1 on page 4). Examiner states that TCP teaches of checking a checksum at 
the receiver to ensure that the segment is not damaged (paragraph 3 on page 4). Examiner states 
that TCP does not explicitly teach of the data signal being used to modify the operation of the 
receiving device. Examiner states that TCP teaches of the use of acknowledgements (ACKs) to 
inform the sender that a packet has been received (paragraph 1 on page 10). Examiner states that 
TCP teaches of the use of PUSH commands (paragraphs 5-7 on page 12) to modify the operation 
of the receiver to "push" the data immediately. Examiner states that TCP teaches of modifying 
the operation of the receiver (and sender too) through the use of Asks to inform the receiver to 
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send newer, or older, segments, and through the use of PUSH commands to pass the data on 
immediately. 

As discussed above, nowhere does the TCP specification disclose or suggest an integrity 
element as defined by Applicants. Nowhere does the TCP specification disclose or suggest 
vaUdating the contents of a frame by an integrity element. The TCP specification teaches a 
header containing required information (final paragraph on page 17) such as routing codes, 
control bits, and sequence number). Nowhere does the TCP specification teach or suggest an 
integrity element that contains only validity-related information. Clearly the TCP header and the 
integrity element are used for different purposes and therefore have the need for different 
contents. Since the TCP specification does not teach or suggest each and every element of 
Applicants' claim 28, either expressly or inherently, Applicants* claim 28 (as well as claims 30 
and 3 1 that depend therefrom and that further define the invention) is not made obvious by the 
TCP specification and a rejection under 35 U.S.C. § 103(a) is inappropriate. Therefore, 
Applicants respectfully request the withdrawal of rejections under 35 U.S.C. § 103(a) with 
regards to claims 28-31 for the reasons set forth above. 

Further remarks with regard to the patentable distinctions of Applicants' claimed 
invention over the TCP specification are provided below. 

With respect to claim 30, Examiner states that TCP teaches of an integrity element that 
comprises a size value (paragraph 2 on page 17). Examiner states that it would have been 
obvious to one skilled in the art to include both the checksum operation and seed value. 
Examiner states that the need to transmit the operator along with the integrity element is not 
clear. Examiner states that it is unclear why the checksum operation and seed values are not 
uniformly agreed upon beforehand so as to save bandwidth and calculation time. Please see the 
argument for claim 2. Further, since claim 28 now appears to be allowable, Applicants 
respectfully request the Examiner withdraw the rejection under 35 U.S.C. § 103(a) directed to 
claim 30 and find claim 30 to be allowable. 
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With respect to claim 31, Examiner states that it would have been obvious to one skilled 
in the art to have the data signal contain an XML element. Examiner states that the frame/packet 
can be comprised of almost any type of transferable data. Applicants agree that almost any type 
of transferable data could be included in Applicants' frame. Further, since claim 28 now appears 
to be allowable, Applicants respectfully request that Examiner withdraw the rejection under 35 
U.S.C. § 103(a) directed to claim 31 and find claim 31 to be allowable. 

In view of the absence from any cited reference of Applicants' claimed invention as set 
forth above, Applicants respectfully urge that TCP and Specs, separately or in combination, are 
not sufficient to render the presently claimed invention obvious under 35 U.S.C. § 103. 

On page 27, paragraph 5.1, of the Office Action, Examiner has objected to claim 29 as 
being dependent upon a rejected base claim. Examiner states that claim 29 would be allowable if 
rewritten in independent form including all of the limitations of the base claim and any 
intervening claims. Applicants have herein amended claim 29 according to Examiner's 
suggestion. New claims 32 and 33 depend from allowable claim 29 and are therefore also 
considered to be allowable. 

All pending claims are believed to be in condition for allowance. All dependent claims 
are beUeved to depend upon allowable independent claims, and are therefore in condition for 
allowance. 

The fee for one additional independent claims and two additional dependent claims is 
included herein, however the Commissioner for Patents is hereby authorized to charge any 
deficiencies to or credit any overpayment to Deposit Accoimt No. 03-2410, Order No. 12078- 
140. 
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The following information is presented in the event that a call may be deemed desirable 
by the Examiner: 

PETER J. BORGHETTI (617) 854-4000 



Respectfully submitted, 

Noah J. Temullo, et al., Applicants 



Date: March 17, 2004 



By: 




Peter J. B^t^Mx 
Reg. N</i^45 
Attorney for Applicants 
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